If you plan on having virtual servers on the ESXI box each on different VLANs then it creates an interesting setup. You have to think about each direction of traffic separately from one another to make sure traffic gets tagged. You could even by hand write a quick flow chart. PFsense (tags data vlan10) > switch port 01 (keep tag) > switch port 02 (keep tag) > ESXI (set to Trunk) To trunk in ESXI, I think you set the VLAN-ID to number to 4098, I can check when I get home. This will allow you to have multiple machines on the vswitch to set their own VLANID. If you want to separate them…. create a new vswitch. The "keep tag" is going to be called so many different things depending on your switch. Usually you have three options, use default VLAN (1), Keep tag (whatever the device says it is), and drop tag (means no vlan).

@klarback: What do you think about disabling source port rewriting? I only have one IP phone behind my public IP. I did this to "fix" a lot of other services I have running behind pfSense. http://doc.pfsense.org/index.php/Static_Port I don't think SIP phones randomize or port hop, so it might not make a difference if you're already capable of getting a dialtone and making calls.  However, turn it off and see if it works.

Yes, with OpenVPN.

Your confused, or not explaining what your wanting to do correctly. You can not just use pfsense as your router/gateway/firewall and think magically all data that flows through it is encrypted and or compressed. You can can encrypt data between endpoints using your choice of encryption methods that both endpoints support.  Once you make this specific connection then sure if your encryption method or connection method supports compression that too cold be used. But just use of pfsense as your gateway/router/firewall does not in any way encrypt or compress anything. Now your client could connect to vpn on the outside of pfsense - and that tunnel could be encrypted from anyone between your client and the endpoint from viewing details of said traffic. What exactly are you trying to prevent from leakage, and to whom?

The ISP can access the DSL modem and potentially add an alias interface that can communicate with your network.  Your setup is insecure.

Thank you! Sounds to me like its more trouble than I want to go to, and more complex than I have time for to be honest. That was a nice definitive answer and I greatly appreciate it.

@verbal: That's why I'm confused about his setup– why make the rule a NOT command and specify an internal subnet when a rule allowing traffic to the WAN only makes more sense? The WAN on my pfSense is directly plugged into my cable modem, which receives a DHCP public IP from Comcast. Your WAN subnet is only a small portion of the public internet (check your current public IP address AND network mask). If you want to allow traffic to the internet you can't do so by allowing traffic to your WAN subnet only. Allowing traffic to NOT LAN subnet is a convenient way of allowing traffic traffic to ALL public IP addresses (AND lots of private IP addresses which you don't currently use). Last time I looked at pfSense firewall rules I don't recall seeing an option to specify "ALL public IP addresses" so you either have to make up an alias for "all public IP addresses" or adopt some cunning such as define an alias for private IP addresses and use "NOT private IP addresses" when you mean "public IP addresses". But that is probably a "more advanced" topic than is suitable for the current discussion.

You might consider to use state-of-the-art hardware instead of outdated stuff. Newer systems can be more energy-efficient. One thing is that a more energy-efficient system can often be run fanless. This not only reduces the noise level, but also increases reliability. Another thing is energy cost - at least for users who don't have an electricty flatrate. The break-even point for newer, mor expensive hardware with energy consumption is typically after two years, compared to "some old junk" which is few years old and you can get for free. I keep the "old junk" with it's noise fans around as backup systems, in case the shiny new modern systems fail. Another point of caution: I have experienced that many switches are unreliable. For example, I have several D-Link gigabit switches lying around which will occasionally just "hang" - network traffic doesn't get through any more and the switch has to be power-cycled. I have found that I can reproduce this phenomen simply by pushing 100MBit/s of traffic shrough the switch; it will "hang" after a few minutes. That sucks. What good is a 1000MBit switch which cannot cope with traffic of 10% link capacity? I currently use Cisco gigabit switches. They seem more reliable. Not "Linksys by Cisco"; I've experienced issues with some of these as well!

The industry standard for doing such things in an ISP-type scenario is Netflow. Several options there.

@mrwho: I was here thinking, can I forget the entire bridging thing and do the following: LAN: IP - 10.0.0.254 DHCP Pool - 10.10.0.1 to 10.10.0.254 WLAN: IP - 10.0.0.253 DHCP Pool - 10.0.10.1 to 10.0.10.254 No, the DHCP pool needs to be in the same subnet as the interface IP address. AND you can't have distinct interfaces in the same subnet. @mrwho: Also, if possible, what could be the drawbacks compared to bridging? If you have two interfaces bridged then broadcast traffic gets forwarded between the interfaces and that helps Windows systems "see" each other. If the interfaces are not bridged then broadcast traffic doesn't get forwarded between the interfaces and systems can generally still see each other with the right incantation but not as "transparently".

@webdawg: Could you not resize it with gparted? with tools along those lines it may be possible, I've never tried that with UFS file systems. May be faster to reinstall and restore.

Thanks, ya I'm going to just format and do a full re-install as I noticed after a factory reset there's still package folders and random things still there.

@Aaron: Now I'm trying to determine the most efficient way to pass traffic from my static IP to the firewall that's sitting behind the pfsense IDS. You mean you're using a pfsense box to run the Snort IDS and have another system (presumably also pfsense?) to do the packet filtering ? pfsense's main strengths are as a firewall / NAT gateway and VPN concentrator. And while I haven't yet found the time to test the Snort-pkg improvements by bmeeks, until recently pfsense's Snort-package wasn't "production-ready". If you need/want a single-purpose machine to run IDS, then I would suggest to simply run Snort on a dedicated (typically Linux) box. Btw putting the IDS on the WAN before the fw will pick up lot of "noise".

Did you setup the port that pfsense is connected to as a trunk port?

@azeemmasghar786: hello smith, when we use single WAn interface then traffic going and incoming perfectly but in multiwan condition request go to the server through one wan and come back through 2nd wan.mean ip change.when ip change then account logout. What email service are you trying to connect to?

I configured pfsense with dial on demand and idle timeout zero and it seems to be working.  The checkbox instructions are misleading. Web.

You should be able to use the "serial memstick" image to do a full install for a serial console machine if you want, just make sure to choose the embedded kernel when installing. Also if you really want it to stay RW at all times, on 2.1-BETA there is an option to keep the nanobsd disk RW under Diag > NanoBSD.

ah! that makes sense (pun intended)! thx! :)